This invention relates generally to dynamic directory services, and more particularly to the recovery of online sessions for such services.
Current trends in computing suggest that computers are becoming networked to one another on a greater and greater scale. For example, computers that previously were connected to other computers in the same building over a local-area network (LAN) are now commonly connected to other computers all over the world over a wide-area network (WAN), an intranet, or the Internet. The rising prominence of the Internet in fact presages a future where all computers are able to connect with one another over a single vast global network.
With this rise in connectivity comes the need for easier recovery from the effects of client, server, and network crashes on directory services for such networks. One type of directory is similar to a phone book. The phone book permits a person to look up the phone number of another person so that the first person can communicate with the second person. Similarly, this type of directory for a computer network permits a computer user to look up the electronic address of another computer user (for example, the user""s current dynamic Internet Protocol (IP) address in the case of a typical home Internet user), so that the first user can communicate with the second user. Although directory services may be used for a wide variety of different applications other than just to locate a user by looking up his or her electronic address, such user-location applications are nevertheless very common. For example, being able to determine the current IP address of a computer user is a very important feature for such diverse Internet applications as Internet telephony, whiteboarding, and videoconferencing.
However, unlike the phone book, which is a static directory, the directory for a computer network such as the Internet frequently must be dynamic in order to be useful. The phone book is a static directory in that it is not updated very often, typically only once a year when a new book is published. The phone book remains accurate, however, because each person""s phone number generally also does not change very often. Conversely, in the case of the Internet, while every user may have a static electronic mail address (that is, an e-mail address that does not change often), every user typically does not have a static IP address. Dial-up users in particular are assigned a dynamic IP address by their Internet Service Provider (ISP) each time they initiate an online session. This lessens the accuracy and usefulness of a static directory for many Internet applications.
Static directory services nevertheless do exist for the Internet, and other Internetlike networks. One such static directory service is provided by the Lightweight Directory Access Protocol (LDAP). The LDAP is known within the art, and is specifically described in W. Yeong, et al., Request for Comments (RFC) 1777, March 1995, which is hereby incorporated by reference. The LDAP permits a server to maintain a static directory. Clients capable of communicating with the server are able to add entries to the directory by sending the server the appropriate request. These entries are static in that they persist until the client establishing them requests their removal from the server. If clients forget to make such requests, the server may maintain their entries in the directory indefinitely, which in time may result in the directory including outdated information. For example, if the server is maintaining a user-location directory of IP addresses, an entry containing the dynamic IP address of a client who has since logged off the Internet is inaccurate.
Dynamic directory services differ from static directory services in that entries must be periodically refreshed by their clients, or otherwise they automatically are removed by the server. Dynamic directory services also exist for the Internet, and other Internet-like networks. One such dynamic directory service is provided by the User Location Service (ULS). The ULS is known within the art, and is specifically described in R. Williams, Internet Draft xe2x80x9cdraft-uls-1.txtxe2x80x9d, February 1996, which is hereby incorporated by reference. A server maintaining a dynamic directory as provided by the ULS is receptive to requests from clients to add entries to the directory that include a time-to-live value set by the client. If the client does not refresh its entry before the time-to-live value times out, the server is permitted to delete the entry. Thus, if the server is maintaining a user-location directory of IP addresses, an entry containing the dynamic IP address of a client who has since logged off will eventually be deleted by the server.
The time-to-live value is related to a period called the client refresh period. The client refresh period is how often the client refreshes its entry with the server. Ideally, the client refresh period could be set to the time-to-live value, since the client need only refresh its entry with the server before the time-to-live value times out in order to maintain the entry in the directory. However, because refresh requests may become lost, or even because of delays in transmitting the message to the server or delays in processing the message at the server, for practical reasons the client refresh period is usually set to a time period less than the time-to-live value. For example, a client refresh period of five minutes and a time-to-live value of ten minutes ensures that a client""s entry will not be deleted by the server even if every other refresh request sent by the client does not get through to the server.
Another dynamic directory service is an extension to the LDAP as described in the U.S. patent application entitled xe2x80x9cServer-Determined Client Refresh Periods for Dynamic Directory Services,xe2x80x9d filed on Jul. 2, 1997, Ser. No. 08/886,796, now U.S. Pat. No. 6,016,508 issued on Dec. 21, 1999, which is hereby incorporated by reference. The dynamic directory service provided by this reference extends the capability of an LDAP directory to include dynamic entries. Thus, when a client sends a request to a server to create an entry for an LDAP directory maintained by the server, the client is able to specify whether the entry to be created is dynamic or static. If the entry is dynamic, the client must immediately send a refresh request to the server, in response to which the client will receive a response including a client-refresh period. If the client does not send another refresh request prior to the timing out of this period, the entry will eventually be deleted by the server.
Dynamic directories are useful in that they permit the servers maintaining them to periodically perform a garbage collection operation in a manner which does not affect the directories"" accuracy. An entry in a dynamic directory is dynamic in that it lives for only a given period of time unless refreshed by its client. The server thus only deletes expired entries. By comparison, servers maintaining static directories perform garbage collections indiscriminately, because they do not know which entries have expired. The servers may delete only very old entries, which probably are outdated, but this means the entries will have persisted long enough to have rendered the directories inaccurate for a period of time. Alternatively, the servers may delete relatively younger entries, in which case the accuracy of the directory is maintained but some accurate entries will likely have been deleted.
Dynamic directories have their own flaws, however. A problem with dynamic directories is a clientxe2x80xa2 s ability to recover from the client crashing, or automatically recover when the server or the network linking the client to the server crashes. For example, once a client has established an entry with a server maintaining a dynamic directory, the client may have difficulty reestablishing the entry upon rebooting after a crash. When attempting to reestablish the same entry with the server (for example, relog onto the server), the server may not permit the client to reestablish the entry, since the entry previously established by the client may still persist on the dynamic directory. The client may have no choice other than to wait a complete client-refresh period, and then hope the server deletes the entry promptly after the entry has expired. This is because typically the server does not permit duplicate entries from the same client, even though the server may allow different entries from the same client.
The client may also have difficulty recovering even when it is not at fault, such as when the network linking the client to the server crashes, or when the server itself crashes. For example, when the network crashes, the server may not receive requests sent by the client to refresh its entry in the dynamic directory maintained by the server. If the crash persists long enough, the entry may time out, and be deleted by the server. When the network finally comes back up, the server may receive another refresh request from the client, but not be able to locate the entry to which the refresh request pertains in the dynamic directory. The server thus responds to the client by sending a xe2x80xa2 no such objectxe2x80xa2 or other error message, which typically requires user intervention at the client in order to reestablish the entry with the server (for example, relog onto the server).
As another example, when the server itself crashes and is forced to reboot (reset), it typically will begin with a new dynamic directory, void of any entries. The dynamic directory, because of the frequency at which it typically is updated, is usually stored in volatile memory, such as random-access memory, instead of being stored on a more permanent storage device, such as a hard disk drive. Thus, the dynamic directory is lost when the server crashes and must be reset. Even if the dynamic directory is periodically backed up to a storage device such as a hard disk drive, the directory may not be completely up-to-date, and the entry established by the client may not reside within the backed-up version of the directory. Therefore, when the server receives a refresh request from the client after rebooting, it may not be able locate the entry to which the request pertains in the dynamic directory. The server again responds to the client by sending an error message to the client, which results in user intervention at the client in order to handle the message and reestablish the entry with the server.
There is a need, therefore, to solve these recovery problems. Such a solution should permit a client to reestablish its entry with a server after the client has crashed, without having to wait for the server to delete the entry after it has timed out. The solution should also permit the client to recover, without user intervention at the client, from a server or network crash that results in a dynamic directory maintained by the server not containing the entry for the client.
The above-mentioned shortcomings, disadvantages and problems are addressed by the present invention, which will be understood by reading and studying the following specification. To solve the recovery problem when a client crashes, one aspect of the invention calls for a unique token for each client. The server is aware of each token, and each token may itself be created by either the server, or the client for the token. When a client crashes after having already logged onto the server, it is able to relog back onto the server by using its token. The server permits the client to immediately relog onto the server, without the client having to wait for its entry in the dynamic directory maintained by the server to time out and be deleted by the server. For example, the server permits the client to take over its former entry in the directory upon matching the token submitted by the client when relogging onto the server with the token for that client already known by the server.
To solve the recovery problem when the server crashes, or when the network linking each client to the server crashes, another aspect of the invention calls for each client to cache all the information sent from the client to the server when first logging onto the server. When either the server or the network crashes, such that the dynamic directory maintained by the server no longer contains an entry for the client, the client is able to use the cached information to automatically relog back onto the server without user intervention. For example, the client may send a refresh request to the server, not knowing that its entry in the dynamic directory is no longer there. In response to receiving an error message from the server (that is, a message notifying the client to log back onto the server), the client resends the information cached from its first log-on to relog onto the server. The client can do this automatically, without having to ask the user at the client to reinput the information it had previously entered during the first logon.
The present invention describes systems, clients, servers, methods, and computer-readable media of varying scope. The two aspects of the invention described in this summary may be utilized separately, or together. In addition to the aspects and advantages of the present invention described here, further aspects and advantages of the invention will become apparent by reference to the drawings and by reading the detailed description that follows.